Building management with remote configuration

ABSTRACT

A building management system and method for configuring the same are disclosed, the building management system comprising a front end device networked to a plurality controller devices. Each controller devices is adapted to transmit a configuration data request if not sufficiently configured to perform its appointed role and the front-end device is adapted to respond to such a configuration data request by broadcasting a configuration data response containing the required configuration data to all the controller devices. Each broadcast configuration data response further includes sufficient information to enable each controller device to determine whether to act on or ignore the broadcast configuration data response

The present invention relates to a novel Building Management System andmethod for the configuration thereof.

Building Management Systems (BMS) are used to perform environmentalcontrol and energy management functions within commercial buildings andfactories, and may exercise control over a variety of factors rangingfrom the mundane (eg. room temperature, room humidity) to the critical(eg. manufacturing parameters, security, life support and so on). Theytypically comprise embedded devices known as controller devices (orsimply controllers), which perform data acquisition and some form ofcontrol and reporting activities. These controllers are networkedtogether using a communications system with a front-end device (forexample a personal computer or other suitable type of data processor) asa means of providing a user interface to the system.

The communications system used in BMS has traditionally been based onproprietary architecture. However, within the past few years, anincreasing number of BMS manufacturers have embraced industry standardcommunication architectures such as those used in standard IT(Information Technology) and office based systems. This has enabled themanufacturer to take advantage of industry standard techniques that areprevalent in such systems.

One of the major challenges faced by the installers of BMS is to be ableto perform fast and accurate system configuration; this is especiallycritical when the system consists of a large number of controllers(>20). Typically, system configuration is a two-stage process; the firststage requires the installer/engineer to manually enter data (includingat least a device number and Internet Protocol (IP) address) into eachcontroller using a dumb terminal or a laptop PC. The second stageinvolves the downloading of the complete configuration data from thefront-end device. This process, however, can lead to a number ofpotential problems, as will be explained below in greater detail, withreference to FIG. 1.

FIG. 1 shows, in outline, the network layout of a standard BuildingManagement System. The system comprises a plurality of controllers 1 anda server 2 (normally a PC, which operates as the front-end device). Oneor more routing devices 3 (routers) are used to create a hierarchicalnetwork layout, whereby the server 2 “sits” on the backbone network andthe controllers 1 are clustered on one or more sub-networks. Both thecontrollers 1 and the server 2 use IP technology (IP addressing androuting), which allows standard “off-the-shelf” IP routing devices to beused as the routers 3. In some cases the network may also be utilised byother IT systems 4.

The system is based on a distributed architecture whereby thecontrollers 1 are highly intelligent in that they can perform complexcontrol functions. Once set-up, the controllers 1 are fully capable ofoperating without any user intervention and do not necessarily requirethe use of a front-end application running on the server 2. This isachieved by a thorough configuration of the controllers 1 duringinstallation stage.

The installation of the system involves the following stages:

-   1. The installer lays-out the communication lines (or uses existing    ones if appropriate) and powers-up the controllers; this ensures    that each controller is operational. At this stage, the controller    is in a “non-commissioned” state. Once this process is complete, the    installer then hands over the site to the commissioning engineer.-   2. The commissioning engineer partially configures each controller    on-site (using a hand-held device e.g., terminal or a notebook PC),    by giving each controller a unique device identifier and an IP    address. The controllers remain in their un-commissioned state,    although it is now possible to communicate with the devices given    that each has an IP address.-   3. On the server, the engineer defines each controller by specifying    its device identifier and IP addresses and inputting additional    configuration data such as control algorithms, cross-references    and/or other parameters.-   4. The final stage involves the manual download of the configuration    data input at step 4 to each of the controllers. Each controller,    upon receiving the data, performs a reset and restarts with the new    parameters—the controller will then be in a “commissioned” state.

Once all the controllers on the site have been commissioned, the BMSsystem can then operate normally.

However, setting up a BMS in the manner described above can suffer froma number of potentially very serious drawbacks. A typical medium sizedBMS site can have around 40+ controllers, but in most cases BMS projectsinvolve large buildings where the number of controllers can reach the100s. One of the largest BMS sites currently in operation has 520controllers and current predictions indicate that this will become atypical figure for future BMS sites.

In a medium sized site (with 40+ controllers) the above configurationprocess can be long and tedious; typically the configuration time is inthe order of about 5-10 minutes per controller, which translates intoabout 4 hours of configuration time. This overhead can have majorimplication on project costs as well as the time to complete the siteconfiguration.

Furthermore, where a commissioning process involves different stages ofconfiguration, there exists a high probability that an engineer couldinadvertently make mistakes. The configuration process involves enteringa number of system parameters such as Device Identifier, IP addresses,Default & Backup Server information. In particular, errors may be causedby having to manually enter IP address configuration, such astypographical errors and/or address conflicts caused by a currentlyassigned IP address accidentally being reissued to another controller.

In some cases, the error may be such that the controller may appear tothe commissioning engineer as being fully operational even though wrongparameters were accidentally used. Here the mistakes are not detecteduntil the site is up and running. This can often lead to a dangeroussituation when the controllers are geared towards managing complexplants and machinery.

It will be apparent from the above that the current configurationprocess provides a good deal of scope for error during configurationstage. This, together with the actual time required to set-up the site,can lead to unexpected delays and costs.

One possible alternative to using the current configuration processwould be to make use of the Dynamic Host Configuration Protocol (DHCP)to partly automate the process.

Dynamic Host Configuration Protocol (DHCP) is a standard protocoldefined by RFC (Request For Comment) 1541 (which is superseded by RFC2131) that allows a server to dynamically distribute IP addressing andconfiguration information to clients (remote terminals) over a network.Normally the DHCP server provides the client with at least the followingbasic information—IP Address, Subnet Mask and Default Gateway.

Other information can be provided as well, such as Domain Name Service(DNS) server addresses and Windows Internet Name Service (WINS) serveraddresses. The system administrator configures the DHCP server with theoptions that are to be parsed out to each client.

Dynamic Host Configuration Protocol was derived from the Internetstandard Bootstrap Protocol (BOOTP) (RFCs 951 and 1084), which alloweddynamic assignment of IP addresses (as well as remote booting ofdiskless workstations). In addition to supporting dynamic assignment ofIP addresses, DHCP supplies all configuration data required by TCP/IP,plus additional data required for specific servers.

As will be explained in greater detail below, the DHCP potentiallyallows the network administrator to configure a plurality of clientterminals by manually configuring just one machine—the DHCP server.Whenever a new host is plugged into the network segment that is servedby the DHCP server (or an existing host is turned back on), the machineasks for a unique IP address, and the DHCP server assigns it one fromthe pool of available IP addresses.

The DHCP client configuration process, as shown in FIG. 2, involves justfour steps: The DHCP client 5 asks for an IP address (DHCP Discover), isoffered an address (DHCP Offer) by the DHCP server 6, accepts the offerand requests the address (DHCP Request), and is officially assigned tothe address (DHCP Acknowledge).

To make sure addresses are not wasted, the DHCP server 6 places anadministrator defined time limit on the address assignment, called alease. Halfway through the lease period, the DHCP client 5 requests alease renewal, and the DHCP server 6 extends the lease. This means thatwhen a machine stops using its assigned IP address (for example, onbeing moved to another network segment or being retired), the leaseexpires, and the address is returned to the pool for reassignment.

Deploying DHCP on enterprise networks therefore provides the followingbenefits:

-   1. Safe and reliable network configuration;    -   a. DHCP minimises configuration errors caused by manual IP        address configuration, such as typographical errors;    -   b. DHCP minimises address conflicts caused by a currently        assigned IP address accidentally being reissued to another        computer;-   2. Reduced network administration;    -   a. TCP/IP configuration is centralized and automated;    -   b. network administrators can centrally define global and        subnet-specific TCP/IP configurations;    -   c. clients can be automatically assigned a full range of        additional TCP/IP configuration values by using DHCP options;    -   d. address changes for client configurations that must be        updated frequently, such as remote access clients that move        around constantly, can be made efficiently and automatically        when the client restarts in its new location; and    -   e. most routers can forward DHCP configuration requests,        eliminating the requirement of setting up a DHCP server on every        subnet, unless there is another reason to do so.

As a result DHCP and its associated components form a powerful andindispensable tool within the IT industry. It is a key component of theTCP/IP suite and widely accepted as a major industry standard. However,despite this fact, using DHCP also presents a number of challenges andshortcomings when applied to the Building Management Systems.

A underlying principle of DHCP is that it relies on allocating IPaddresses on a first-come-first-serve basis—ie. the IP addresses aredynamically allocated. It is therefore inherent in a DHCP system that aDHCP client is not guaranteed the same IP address every time it re-joinsthe network, and consequently a typical service or application cannotrely on IP addresses alone to access information. This, in the ITindustry, is resolved by using a naming convention (supported by theDomain Name Service, or DNS for short) in which each device is known byits unique name; the underlying services translate the name into an IPaddress that has been allocated by the DHCP server.

Within a BMS application, applications also refer to other applicationsor services using a naming convention with the underlying functionstranslating device names into their respective IP addresses. However,with any real-time closed loop control system, the use of dynamicallyallocated IP addresses presents a number of problems. It is not uncommonfor Controllers to perform automatic resets, known as Warm Resets, whichunlike Cold Resets preserve existing control parameters (other than theIP address) and ensure that the system carries on functioning in themanner it did before the reset. If the IP address and other informationwere obtained dynamically, the warm reset together with other actionsthat the Controller may take will require the use of the DHCP services.Whilst this may be acceptable, the reliance on a DHCP server does raisethe issue of the DHCP server becoming a single point of failure i.e.,loss of the server will mean that parts of the BMS are unable tocommunicate and be controlled normally. The consequence of this could bequite catastrophic in some cases. The need for a reliable anddeterministic control system such as the BMS dictates for staticallyallocated parameters that are guaranteed not to change during theoperation of the system.

Also, a number of BMS consist of controllers that work in physically &geographically isolated locations. These controllers often use a dial-upmechanism to send information to the BMS Server as well as to othercontrollers in other locations. The use of a dial-up mechanism meansthat the DHCP cannot be used as primary means of configuring thesecontrollers.

As is apparent from the above, while the DHCP is commonly used within anIT environment, it is unlikely in most circumstances to adequatelyaddress the needs of the Building Systems & controls industry.

According to one aspect of the present invention, a building managementsystem is provided comprising a front end device networked to aplurality of controller devices, each controller device being adapted totransmit a configuration data request if not sufficiently configured toperform its appointed role and the front-end device being adapted torespond to such a configuration data request by broadcasting aconfiguration data response containing the required configuration datato all the controller devices, each broadcast configuration dataresponse including sufficient information to enable each controllerdevice to determine whether to act on or ignore the broadcastconfiguration data response.

According to another aspect of the present invention, a method ofconfiguring a building management system comprising a front end devicenetworked to a plurality of controller devices is provided, the methodcomprising:

-   a) programming each controller device to check whether or not it has    sufficient configuration data to perform its appointed role and, if    not, to transmit a configuration data request; and-   b) programming the front end device to respond to a configuration    data request from a controller device by broadcasting a    configuration data response to all the controller devices, each such    configuration data response comprising the configuration data    required by the controller device that transmitted the configuration    data request and sufficient information to enable each controller    device to determine whether to act on or ignore the configuration    data response.

Preferably, the configuration data responses are IP multicasttransmissions, the controller devices all sharing the same IP multicastaddress.

Each configuration data response may include a controller deviceidentifier identifying the controller device that requires theconfiguration data, each controller device being adapted to act only ona configuration data response containing its respective controllerdevice identifier.

Each configuration data request may include a controller deviceidentifier identifying the controller device sending the configurationdata request, the front end device being adapted to check the controllerdevice identifier in any incoming configuration data request in order todetermine the configuration data required.

Preferably, each controller device is adapted to broadcast aconfiguration data request to all the other controller devices and thefront end device, each such configuration data request includingsufficient information to enable each device receiving it to determinewhether to act on or ignore the configuration data request. Where thisis the case, the configuration data requests are preferably IP multicasttransmissions, the front end device and controller devices all sharingthe same IP multicast address.

Each configuration data request and each configuration data response mayinclude a transmission type identifier identifying the transmission typeas a request or response, the controller devices being adapted to actonly on responses and the front end device being adapted to act only onrequests.

Each controller device may be adapted to check on power-up whether ornot it has sufficient configuration data to perform its appointed role.

Each controller device may be adapted to retain, once configured, itsconfiguration data in the event of a restart.

Each controller device may be adapted to re-transmit a configurationdata request if it has not received an acceptable configuration dataresponse within a predetermined interval.

As explained above, in a conventional BMS, each data transmission isdirected towards one or more specific recipients each identified by aunique IP address (such transmissions sometimes being referred to as IPunicasting or point-to-point messaging). However, in the presentinvention, each configuration data response is broadcast such that it istransmitted to all the controllers, the contents of the transmission orbroadcast itself enabling each controller to determine whether or notthe transmission is of relevance to it. Likewise, configuration datarequests from the controllers are preferably similarly broadcast.

As noted, a preferred method of ensuring that each configuration datarequest and response are directed to all the controllers and the serveris to make use of IP multicast transmissions. In IP multicasting, eachdevice in a specified group is assigned the same IP address (a so-calledmulticast address) and any transmission sent to this address is routedby multicast routers to each device in that group. Thus the transmissionconcerned is in essence broadcast to a specified set or group ofdevices. This is in general to be preferred to forms of IP broadcastingin which each data transmission is sent to any and every deviceconnected to a network, so as to avoid erroneously transmittingconfiguration data responses or requests to third party devices that maybe present on the network—ie. by assigning the multicast address only tothe front end device and the controllers, the BMS transmissions can beisolated from any other unrelated devices/hardware that may be sharingthe same IP network.

An embodiment of the invention will now be described, by way of example,with reference to the accompanying Figures, in which:

FIG. 1 is a schematic showing, in outline, the network layout of astandard Building Management System (prior art);

FIG. 2 is a schematic illustrating the DHCP client configuration process(prior art);

FIG. 3 is a schematic illustrating an Internet Protocol & UDP payloaddata transmission;

FIG. 4 is a flow chart of a Controller configuration process inaccordance with the present invention, from the perspective of aController; and

FIG. 5 is a flow chart of the configuration process of FIG. 4, from theperspective of the Server.

A Building Management System according to the present embodiment of theinvention comprises a conventional network layout as described above inrelation to FIG. 1, ie. the system comprises a plurality of controllers1 connected to a server 2 via one or more routers 3 so as to form ahierarchical network layout, with the server 2 connected to the backbonenetwork and the controllers 1 clustered on one or more sub-networks.

The controllers 1 store all configuration data in long-term memory suchas battery-backed RAM or EEPROM or FLASH memory devices and that alldevices, prior to configuration, will have all configuration parametersset to zero or a known value. Every controller also maintains a flag,known as the Commissioning Flag, in its long-term memory. This flag isinitialised to a “non-commissioned” state prior to the controllerreceiving its configuration data. Prior to its configuration, eachcontroller is also assigned a unique device identifier which is hardcoded or stored in its long term memory.

In order to make use of IP multicasting, the server 2 (there may be morethan one) is required to register a multi-cast IP address, whichcurrently lie in the range 224.0.0.0 through to 239.255.255.255, at alltimes. This allows the server 2 to receive data that is transmittedusing the multi-cast address. All intermediate routers 3 are adapted toforward data addressed using this multi-cast address.

Referring now to FIG. 3, the configuration data transmissions from thecontrollers and the server are encapsulated within an IP & UDP (UserDatagram Protocol) payloads. These payloads comprise an IP header 7 anda UPD header 8. The UDP header 8 has a checksum option and it isrecommended that this option be enabled so that the integrity of alldata transfers can be maintained.

In addition to the IP and UDP headers 7, 8, each transmission alsocomprises the following data fields:

-   a) a Data Type field 9 containing data that indicates whether the    transmission is a “configuration data request” (which identifies the    transmission as originating from a controller requiring    configuration data) or a “configuration data response” (which    identifies the transmission as a response originating from the    server);-   b) a Device Identifier field 10 containing the unique device    identifier of the controller that requires configuration data;-   c) in the case of a typical BMS site, comprising different    controller types (in the sense of having different functions and/or    roles), a Controller Device Type field 11 containing data that    indicates the type of controller that requires configuration data;    and-   d) a Configuration Data field 12—where the data transmission is a    configuration request (ie. it originates from a controller requiring    configuration data) no data will be contained in this field,    however, where the data transmission is a configuration data    response (ie. a response from the Server to a configuration request)    this field will contain the required configuration data for the    controller in question.

Referring now to the controller flow chart of FIG. 4, upon power-up 14 acontroller decides if it needs to request for configuration data fromthe server. This request is only made if the controller's checksindicate that it has been given a unique identifier (check 15) and is innon-commissioned state (check 16).

The controller registers 17 the pre-determined multicast IP address—thisallows the controller to send data to all devices using the IP address.It then sends a configuration request 18 to the server and since theData Type is set to Request, all other controllers will ignore this datapacket.

The controller then sets a timer 19 and awaits a response from theserver. If the timer expires (check 21) before the response is received(check 20), a new configuration request 18 is dispatched. Once aresponse is received from the server, the controller verifies the data22 and updates the configuration area within its long-term memory. Italso sets the Commissioning Flag to “commissioned” state 23, thusensuring that no further requests are sent to the server. The controllerthen performs a reset 24 and starts-up with the new configurationparameters—upon restart, the controller does not need to re-register themulticast IP address, but instead proceeds to normal operation of thedevice 25.

Referring now to the server flow chart of FIG. 5, once the server hasbeen powered up 26, initialised all tasks and applications 27, andregistered 28 the multicast IP address, the server waits 29 for anyin-coming Configuration Request packet. Once received, it verifies 30the Controller Identifier and Type against a locally stored database ofcontroller configuration. If the Server does not recognise the device,it will generate an alarm 31 so that the operator can take appropriateaction, otherwise it will send 32 the required configuration data to thedevice using the multicast IP address. Since the IP data packet containsa field identifying the Controller by its unique identifier, all otherControllers will ignore this data packet.

A comparison of the known method of configuring a BMS, as describedabove, with the configuration method described in relation to thepresent embodiment, is shown below in Table 1. As is apparent therefrom,in the present embodiment the configuration process is simplified, whencompared to a standard BMS and configuration process, thus saving timeand cost of installation and reducing the chances of errors occurringduring configuration process.

The technique described here is not confined to one specific BMS butinstead can be used with any BMS that is based on IP technology.

The foregoing broadly describes the present invention, withoutlimitation. Variations and modifications as would be apparent to thoseof ordinary skill in the art are intended to be comprised within thescope of this application and subsequent patent(s). TABLE 1 USING METHODOF STAGE USING KNOWN METHOD PRESENT EMBODIMENT. 1 The installer lays-outthe Same as before. communication medium (or uses existing ones ifappropriate) and powers-up the Controllers; this ensures that theController is operational. 2 The commissioning engineer Only a uniquedevice id partially configures each need be provided. Controller on-siteby pro- viding a device id and unique IP address. 3 On the front-enddevice, the Only the device id need be set-up application requiresspecified, with the addi- the engineer to define each tionalconfiguration data Controller by specifying its being input as before -device id and IP address and in both cases, the set-up inputting theappropriate application may validate additional configuration theadditional configura- data. tion data. 4 The additional input config-The additional configura- uration data is downloaded tion data for eachcontrol- individually to each of the ler is broadcast as a Controllersusing the multi-cast transmission specified IP addresses. Eachcontaining the specified Controller, upon receiving device id. Eachcontroller the additional data, performs determines which transmis- areset and restarts with the sion is appropriate to it new parameters.and performs a reset and restart as before.

1. A building management system comprising a front end device networkedto a plurality of controller devices, each controller device beingadapted to transmit a configuration data request if not sufficientlyconfigured to perform its appointed role and the front-end device beingadapted to respond to such a configuration data request by broadcastinga configuration data response containing the required configuration datato all the controller devices, each broadcast configuration dataresponse including sufficient information to enable each controllerdevice to determine whether to act on or ignore the broadcastconfiguration data response.
 2. A building management system accordingto claim 1, wherein the configuration data responses are IP multicasttransmissions, the controller devices all sharing the same IP multicastaddress.
 3. A building management system according to claim 1, whereineach configuration data response includes a controller device identifieridentifying the controller device that requires the configuration data,each controller device being adapted to act only on a configuration dataresponse containing its respective controller device identifier.
 4. Abuilding management system according to claim 1, wherein eachconfiguration data request includes a controller device identifieridentifying the controller device sending the configuration datarequest, the front end device being adapted to check the controllerdevice identifier in any incoming configuration data request in order todetermine the configuration data required.
 5. A building managementsystem according to claim 1, wherein each controller device is adaptedto broadcast a configuration data request to all the other controllerdevices and the front end device, each such configuration data requestincluding sufficient information to enable each device receiving it todetermine whether to act on or ignore the configuration data request. 6.A building management system according to claim 5, wherein theconfiguration data requests are IP multicast transmissions, the frontend device and controller devices all sharing the same IP-multicastaddress.
 7. A building management system according to claim 5, whereineach configuration data request and each configuration data responseincludes a transmission type identifier identifying the transmissiontype response, the controller devices being adapted to act only onresponses and the front end device being adapted to act only onrequests.
 8. A building management system according to claim 1, whereineach controller device is adapted to check on power-up whether or not ithas sufficient configuration data to perform its appointed role.
 9. Abuilding management system according to claim 1, wherein each controllerdevice is adapted to retain, once configured, its configuration data inthe event of a restart.
 10. A building management system according toclaim 1, wherein each controller device is adapted to re-transmit aconfiguration data request if it has not received an acceptableconfiguration data response within a predetermined interval.
 11. Amethod of configuring a building management system comprising a frontend device networked to a plurality of controller devices, the methodcomprising: a. programming each controller device to check whether ornot it has sufficient configuration data to perform its appointed roleand, if not, to transmit a configuration data request; and b.programming the front end device to respond to a configuration datarequest from a controller device by broadcasting a configuration dataresponse to all the controller devices, each such configuration dataresponse comprising the configuration data required by the controllerdevice that transmitted the configuration data request and sufficientinformation to enable each controller device to determine whether to acton or ignore the configuration data response.
 12. A method according toclaim 11, comprising programming the front end device to sendconfiguration data responses using an IP multicast address registered orto be registered by the controller devices.
 13. A method according toclaim 11, comprising programming the front end device to include acontroller device identifier identifying the controller device thatrequires the configuration data in each configuration data response andprogramming each controller device to act only on a configuration dataresponse comprising its respective controller device identifier.
 14. Amethod according to claim 11, comprising programming each controllerdevice to include in each data request it sends a controller deviceidentifier identifying itself and programming the front end device tocheck the controller device identifier in any incoming configurationdata request in order to determine the configuration data required. 15.A method according to claim 11, comprising programming each controllerdevice to broadcast a configuration data request to all the othercontroller devices and the front end device, each such configurationdata request including sufficient information to enable each devicereceiving it to determine whether to act on or ignore the configurationdata request.
 16. A method according to claim 15, comprising programmingthe controller devices to send configuration data requests using an IPmulticast address registered or to be registered by all the controllerdevices and the front end device.
 17. A method according to claim 15,comprising programming the controller devices and front end device toinclude a transmission type identifier in any configuration data requestor configuration data response being sent identifying the transmissiontype as a request or response and programming the controller devices toact only on responses and the front end device to act only on requests.18. A method according to claim 11, comprising programming eachcontroller device to check on power up whether or not it has sufficientconfiguration data to perform its appointed role.
 19. A method accordingto claim 11, comprising programming each controller device to retain,once configured, its configuration data in the event of a restart.
 20. Amethod according to claim 11, comprising programming each controllerdevice to re-transmit a configuration data request if it has notreceived an acceptable configuration data response within apredetermined interval.
 21. (canceled)
 22. (canceled)